テクニカルレポート | GRACEセンター

(1)

ISSN 1884-0760

GRACE TECHNICAL REPORTS

Proceedings of the Third International

Workshop on Software Patterns and Quality

(SPAQu’09)

Hironori Washizaki, Nobukazu Yoshioka, Eduardo B.

Fernandez and Jan J¨

urjens (editors)

GRACE-TR 2009–07

October 25, 2009

CENTER FOR GLOBAL RESEARCH IN

ADVANCED SOFTWARE SCIENCE AND ENGINEERING

NATIONAL INSTITUTE OF INFORMATICS

2-1-2 HITOTSUBASHI, CHIYODA-KU, TOKYO, JAPAN

(2)

(3)

Overview of the 3rd International Workshop

on Software Patterns and Quality (SPAQu’09)

Hironori Washizaki

Waseda University / GRACE Center, National Institute of Informatics 3-4-1, Okubo, Shinjuku-ku, Tokyo,

Japan [email protected]

Nobukazu Yoshioka

National Institute of Informatics 2-1-2 Hitotsubashi, Chiyoda-ku,

Tokyo, Japan [email protected]

Eduardo B. Fernandez

Florida Atlantic University 777 Glades Road, Boca Raton, FL

33431, USA [email protected]

Jan Jurjens

TU Dortmund / Fraunhofer ISST [email protected]

Abstract

We will discuss here the theoretical, social, technological and practical issues related to quality aspects of software patterns including security and safety aspects. The work-shop will provide the opportunity for bringing together re-searchers and practitioners, and for discussing the future prospects of this area. As for the workshop format, first, we will have short talks on what software patterns are, and how they are related to quality. Second, we will have accepted position paper presentations to expose the latest researches and practices on software patterns and quality. Finally, we will discuss several topics related to these presentations in small groups. Newcomers, interested researchers and practi-tioners are free to attend the workshop to facilitate their un-derstandings, researches and practices on software patterns and quality.

Categories and Subject Descriptors D.2.10 [Software En-gineering]: Design; D.2.11 [Software Engineering]: Soft-ware Architectures; D.2.13 [Software Engineering]: Reusable Software; D.3.3 [Programming Languages]: Language Con-structs and Features

General Terms Design, Experimentation, Measurement Keywords Software Patterns, Software Quality, Design Patterns, Security Patterns

Copyright is held by the author/owner(s).

OOPSLA 2009, October 25–29, 2009, Orlando, Florida, USA. ACM 978-1-60558-768-4/09/10.

1. Main Theme and Goals

As requirements for software products and processes have become more complex, larger scale and have begun to in-clude higher reliability, demand is increasing for a system of technologies to capture, share, enhance, apply and evalu-ate software patterns. Especially, although numbers of pat-tern catalogs have been published, little known is about how to specify, measure and evaluate those patterns themselves and/or their application results from the viewpoint of quality. Such conditions make it difficult to see the nature of software patterns and pattern-oriented development ways.

To overcome such conditions, the first workshop of this series was held on December 2007 collocated with the Asia-Pacific Software Engineering Conference (APSEC)[1], and it attracted more than 30 people. The second one was held on October 2008 collocated with the Pattern Languages of Programs Conference (PLoP)[2], and it attracted around 10 people. These previous workshops were successful to dcuss the theoretical, social, technological and practical is-sues related to quality aspects of patterns including security and safety aspects.

(4)

2. Possible topics

”Quality” is defined asthe totality of features and charac-teristics of a product or service that bear on its ability to satisfy stated or implied needsin ISO 8402. An important property of software quality is that quality requirements are not limited to functionality and reliability. For example, typ-ical software quality characteristics are classified in ISO/IEC 9126 as the followings: functionality, reliability, usability, efficiency, maintainability and portability. To these we can add security and safety. Quality requirements (as part of non-functional requirements) can be specified for each quality characteristic.

Software patterns can be reused to fulfill software re-quirements including functional and non-functional ones. Currently how to specify quality aspects of patterns applica-tions or of themselves is a remaining big research challenge. Typical existing approaches are the followings:

•Qualitative analysis of relationships among quality at-tributes (characteristics) and patterns, such as software quality assessment[4] and architecture trade-off analysis[5].

•Requirements engineering for quality aspects of patterns, such as the goal-oriented analysis of patterns for finer representation and selection[6].

•Quantitative measurements of quality aspects of patterns, such as the design complexity[7] and defect frequency[8] in design patterns application results.

•Emerging quality-specific patterns such as security patterns[9]

However, we believe there is still room to gain an im-proved understanding and further research development on these topics (e.g. how to validate pattern analysis and/or ap-plication results?).

3. Post-workshop activities

After the workshop, we will display a poster summarizing the workshop results at the OOPSLA conference site. More-over, we have a plan to make and put a detailed report on the workshop website[3]. This report will include a summary of discussions so that it will provide a brief summary of the state of the art and future perspectives in the area of soft-ware patterns and quality. Therefore, it should facilitate each participant’s and non-participant reader’s understanding and future research/practice on this area.

Acknowledgments

The workshop will be co-sponsored by the IPSJ/SIGSE Pat-terns Working Group and the GRACE Center of the National Institute of Informatics of Japan (NII).

References

[1] 1st International Workshop on Software Patterns and Quality (SPAQu’07), 2007.

http://patterns-wg.fuka.info.waseda.ac.jp/SPAQU/ result-2007.html

[2] 2nd Workshop on Software Patterns and Qual-ity (SPAQu’08), 2008.

http://patterns-wg.fuka.info.waseda.ac.jp/SPAQU/ result-2008.html

[3] 3rd International Workshop on Software Patterns and Quality (SPAQu’09), 2009.

http://patterns-wg.fuka.info.waseda.ac.jp/SPAQU/ [4] Eelke Folmer and Jan Bosch, ”A Pattern Framework for

Soft-ware Quality Assessment And Tradeoff Analysis,” Interna-tional Journal of Software Engineering and Knowledge En-gineering, Vol.17, No.1, 2007.

[5] Len Bass, Paul Clements and Rick Kazman, ”Software Archi-tecture in Practice,” Addison-Wesley, 2003.

[6] Ivdm Araujo and Michael Weiss, ”Linking Patterns and Non-Functional Requirements,” Proc. of the 9th Conference on Pattern Language of Programs (PLoP 2002), 2002.

[7] Hironori Washizaki, Kazuhiro Fukaya, Atsuto Kubo, Yoshi-aki Fukazawa, ”Detecting Design Patterns Using Source Code of Before Applying Design Patterns,” Proc. of the 8th IEEE/ACIS International Conference on Computer and Infor-mation Science (ICIS 2009), 2009.

[8] Marek Vokac, ”Defect Frequency and Design Patterns: An Empirical Study of Industrial Code,” IEEE Transactions on Software Engineering, Vol.30, No.12, 2004.

(5)

Program Committee

Yijun Yu, The Open University, UK

Yasuyuki Tahara, The University of Electro-Communications, Japan

Soon-Kyeong Kim, The University of Queensland, Australia

Linda Rising, Independent Consultant, US

Eric Platon, Cirius Technologies, Japan

Somjai Boonsiri, Chulalongkorn University, Thailand

Naoyuki Nagatou, Ritsumeikan University, Japan

Yann-Gaël Guéhéneuc, Canada Research Chair on Software Patterns and Patterns of

Software, École Polytechnique de Montréal, Canada

Kenji Tei, Waseda University, Japan

Atsuto Kubo, National Institute of Informatics, Japan

Katsuhisa Maruyama, Ritsumeikan University, Japan

Fuyuki Ishikawa, National Institute of Informatics, Japan

Michael VanHilst, Florida Atlantic University, US

External Reviewers:

Foutse Khomh, DIRO, Universite de Montreal, QC, Canada

(6)

Defining a Catalog of Programming Anti-Patterns for Concurrent Java

Jeremy S. Bradbury, Kevin Jalbert Software Quality Research Group Faculty of Science (Computer Science) University of Ontario Institute of Technology

Oshawa, Ontario, Canada

[email protected], [email protected]

Abstract—Many programming languages, including Java, provide support for concurrency. Although concurrency has many benefits with respect to performance, concurrent soft-ware can be problematic to develop and test because of the many different thread interleavings. We propose a comprehen-sive set of concurrency programming anti-patterns that can be used by Java developers to aid in avoiding many of the known pitfalls associated with concurrent software development. Our concurrency anti-patterns build upon our previous work as well as the work of others in the research community.

Keywords-concurrency, anti-patterns, bug patterns, Java, deadlock, race conditions, static analysis.

I. INTRODUCTION

The widespread adoption of multi-core technologies has made concurrency an essential characteristic of many tradi-tionally sequential programs. The use of concurrency with multi-core systems can provide an increase in performance over sequential code because it allows programs to have multiple threads executing simultaneously. Although concur-rency is beneficial, it can also be problematic. For example, the possibly many different ways to interleave threads in concurrent code make it very difficult to test. Concurrency bugs can be hard to find due to the non-deterministic nature of thread interleavings and because some bugs may occur in only a small subset of the entire interleaving space. It is also challenging to reproduce these bugs and determine if a bug has been fixed or not. In general, concurrency bugs exhibit consequences not present in sequential source code, including deadlock and race conditions. These consequences typically occur because of problems with accessing shared data or controlling access to shared data.

In an effort to improve the quality of concurrent programs there has been considerable effort invested by researchers in developing new programming models, new testing and analysis tools and in identifying concurrency-related design patterns. The development of new concurrent programming models [1] has the potential to make programming with concurrency easier and less error prone. The development of new testing and analysis techniques, as well as the improve-ment of existing techniques, is aimed at identifying more concurrency bugs prior to deployment. The identification of concurrency design patterns complements the previous two

research topics by focusing on how to improve concurrency programming in existing languages in an effort to reduce bugs prior to testing and analysis.

A pattern is defined as something that “...describes a problem which occurs over and over again in our envi-ronment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”[2]. A pattern should include details such as the pat-tern name, the problem, the solution to the problem and the consequences of using the pattern [3]. Alternatively, an anti-pattern defines a recuring bad design solution [4]. The goal of our research is to produce a set of low-level anti-patterns for improving concurrent source code. We have focused our efforts on low-level anti-patterns to complement the previous work on identify concurrency design-level patterns [5], [6]. In Section II we will discuss how to write concurrent programs in Java. We present our concurrency anti-patterns catalog in Section III and provide an example to illustrate the use of the catalog. We also discuss how our catalog can be used to improving concurrency programming, testing and analysis. In Section IV we address how to automatically de-tect potential anti-patterns in source code before presenting our conclusions in Section V.

II. JAVACONCURRENCY

Concurrent Java programs are often called multi-threaded programs. During execution an active thread can be runnable or not runnable and a number of methods exist that can affect a thread’s status:

• sleep(): will cause the current thread to stop executing for a certain amount of time.

• yield(): will cause the current thread that is running to pause and yield the processor to another thread. • join(): will cause the caller thread to wait for a target

thread to terminate.

(9)

blocks. Additionally, synchronization blocks can be used in combination with implicit monitor locks. In J2SE 5.0, additional mechanisms to support concurrency were added as part of thejava.util.concurrent package [7]:

• Explicit Lock: Provides the same semantics as the implicit monitor locks but provides additional function-ality such as timeouts during lock acquisition.

• Semaphore: Maintains a set of permits that restrict the number of threads accessing a resource.

• Latch: Allows threads to wait until other threads com-plete a set of operations.

• Barrier: A point at which threads from a set wait until all other threads reach that point.

• Exchanger: Allows two threads to exchange objects at a given synchronization point.

To reduce the overhead of developing concurrent software J2SE 5.0 also provides a number of other resources:

• Concurrent collection types: ConcurrentHashMap, BlockingQueues.

• Built-in thread pools: FixedThreadPool and an un-bounded CachedThreadPool.

• Atomic variable types: Types that can be used in place of synchronization since each atomic variable type contains special atomic methods. For example,

AtomicIntegercontains a methodsgetAndSet().

III. A CATALOG OFCONCURRENCYANTI-PATTERNS

Prior to J2SE 5.0, Farchi, Nir, and Ur developed a bug pattern taxonomy for Java concurrency [8]. The bug patterns are based on common mistakes programmers make when developing concurrent code in practice. Furthermore, the taxonomy has been expanded and used to classify bugs in an existing public domain concurrency benchmark maintained by IBM Research [9]. Bradbury, Cordy and Dingel further extended the taxonomy in their concurrency mutation re-search [10]. We will use this bug taxonomy as the basis for our concurrency anti-patterns – in fact many of the problems we identify were included in this previous work.

An anti-pattern catalog for Java multithreaded software has already been developed by Hallal et al. [6]. In their work, Hallal et al. distinguish between design anti-patterns and error or bug patterns. The former category focuses on the syntactic design within a program while the latter category focuses on“patterns of erroneous program behav-ior correlated with programming mistakes” [6]. The Hallal et al. pattern catalog primarily contains design anti-patterns, including anti-patterns related to efficiency, quality and style, while our work focuses on the identification of anti-patterns based on bugs and includes anti-patterns related to the correctness of the program. Therefore, we believe that the Hallal et al. catalog and our catalog are complementary. Table I and II provide an overview of all the concurrency

anti-patterns included in our catalog1. For each anti-pattern we provide the following information:

• pattern name: the anti-pattern name is based on the corresponding bug’s name. For example, the two-state access anti-pattern corresponds to the two-state access bug.

• problem:the problem describes the corresponding bug that is being addressed.

• context:the context in which the problem often occurs. • solution: the solution describes general steps that can be taken to correct the anti-pattern. We have made an effort to keep the solutions as general as possible and it is expected that the developer will have the appropriate level of knowledge to understand how to apply the solution in a specific context.

We have not included the consequences of fixing each anti-pattern because in most cases these are evident from the problem section of the anti-pattern. For example, the consequences of applying the solution in theDeadlock anti-patternare that locks will now be released and the threads will no longer halt.

Our catalog of concurrency anti-patterns provides several benefits:

1) The catalog is language specific – it is focused on anti-patterns that can occur in Java and not anti-anti-patterns that occur in general.

2) The catalog is comprehensive – it includes the bug definitions from several different sources [8], [9], [10]. 3) The catalog provides solutions – in addition to enu-merating different kinds of concurrency bugs as anti-pattern problems, we also provide solutions to each anti-pattern.

To demonstrate the use of the catalog we will now de-scribe an example using theDeadlock anti-pattern. Consider the following two code fragments which are executed by different threads:

Code fragment #1:

p u b l i c v o i d methodA ( ){ s y n c h r o n i z e d( l o c k 1 ){

s y n c h r o n i z e d( l o c k 2 ){ } }

}

Code fragment #2:

p u b l i c v o i d methodB ( ){ s y n c h r o n i z e d( l o c k 3 ){

s y n c h r o n i z e d( l o c k 4 ){ } }

}

(10)

Pattern name Problem Context Solution Nonatomic operations assumed to be atomic anti-pattern.*

“...an operation that “looks” like one operation in one programmer model (e.g., the source code level of the programming language) but actually consists of several unprotected operations at the lower abstraction levels” [8].

Trying to perform an operation on a shared data variable atomically.

Use the volatile keyword when using 64-bit variables.

Two-state access bug anti-pattern.*

“Sometimes a sequence of operations needs to be protected but the programmer wrongly assumes that separately protecting each operation is enough” [8].

Trying to protect access to operations involving shared data.

Combine the multiple critical regions into one critical region.

Wrong lock or no lock bug anti-pattern.*

“A code segment is protected by a lock but other threads do not obtain the same lock instance when executing. Either these other threads do not obtain a lock at all or they obtain some lock other than the one used by the code segment” [8].

Identify all accesses to shared data and use the same lock object to protect these critical regions. This may involve added a new lock or replacing incorrect locks with the correct one.

Double-checked lock anti-pattern.*

“When an object is initialized, the thread local copy of the objects ﬁeld is initialized but not all object ﬁelds are necessarily written to the heap. This might cause the object to be partially initialized while its reference is not null” [8].

Trying to initialize shared variables without using protection.

Use locks to synchronize all access to the object or use volatile. Do not perform lazy initialization on shared objects.

The sleep() anti-pattern.*

“The programmer assumes that a child thread should be faster than the parent thread in order that its results be available to the parent thread when it decides to advance. Therefore, the programmer sometimes adds an _ʻappropriate_ʼ sleep() to the parent thread. However, the parent thread may still be quicker in some environment.” [8].

Trying to coordinate threads based on assumptions regarding thread timing.

“The correct solution would be for the parent thread to use the join() method to explicitly wait for the child thread” [8].

Missing or nonexistent signals anti-pattern.+

This pattern generalizes the losing a notify bug pattern to all signals. The losing a notify bug is defined as occurring “If a notify() is executed before its corresponding wait(), the notify() has no effect and is “lost” ... the programmer implicitly assumes that the wait() operation will occur before any of the corresponding notify() operations” [8]. Another example of this problem can occur at a barrier. If an await() from one thread never occurs then all of threads at the barrier may be stuck waiting.

Trying to coordinate threads based on assumptions regarding thread timing.

In the case of a notify signal, “One way of avoiding this bug pattern is to repeatedly execute the notify() operation until a condition stating that the notify() was received occurs”[8]. Use concurrent mechanisms such as barriers and join() to prevent thread timing issues. Analogous solutions exist for other signals.

Notify instead of notify all anti-pattern.**

If a notify() is executed instead of notifyAll() then threads with some of its corresponding wait() calls will not be notified [16].

Trying to coordinate threads.

Replace notify() with notifyAll().

A “blocking” critical section anti-pattern.*

“A thread is assumed to eventually return control but it never does” [8].

Using locks to try and protect access to operations involving shared data.

Ensure that every lock() acquisition has a corresponding unlock(). If it is possible to throw an exception inside a critical region the unlock() must be placed in a finally block. The finally block will be executed regardless if the exception is thrown.

Table I

CONCURRENCY ANTI-PATTERNS CATALOG(Part 1 of 2)

The above fragments are an example of theDeadlock anti-patterniflock1is the same lock object aslock4whilelock2is

(11)

Pattern name Problem Context Solution The

interference anti-pattern.**

A pattern in which “...two or more concurrent threads access a shared variable and when at least one access is a write, and the threads use no explicit mechanism to prevent the access from being simultaneous.” [17]. The interference bug pattern can also be generalized from classic data race interference to include high level data races** which deal “...with accesses to sets of fields which are related and should be accessed atomically” [18].

Trying to use operations involving shared data without protecting the access to the shared data.

Use synchronization to protect both write and read access to shared variables.

The deadlock anti-pattern.**

“...a situation where two or more processes are unable to proceed because each is waiting for one of the others to do something in a deadlock cycle ... For example, this occurs when a thread holds a lock that another thread desires and vice-versa” [17].

Remove unnecessary synchronization if possible. Remove unnecessary nested synchronization if possible. Ensure nested synchronization always occurs in the same order.

Starvation anti-pattern.+

This bug occurs when their is a failure to “...allocate CPU time to a thread. This may be due to scheduling policies...” [5]. For example, an unfair lock acquisition scheme might cause a thread never to be scheduled.

Trying to use concurrency independent of scheduling policies.

When available use fairness parameter for concurrent

mechanisms like semaphores. This will ensure that no thread can unfairly acquire semaphore permits.

Resource exhaustion anti-pattern.+

“A group of threads together hold all of a finite number of resources. One of them needs additional resources but no other thread gives one up” [5].

Trying to optimize a concurrent program by limiting resources.

One solution is to consider allocating additional resources. Another solution is to limit all threadsʼ access to resources.

Incorrect count initialization anti-pattern.+

This pattern occurs when there is an incorrect initialization in a barrier for the number of parties that must be waiting for the barrier to trip, or an incorrect initialization of the number of threads required to complete some action in a latch, or an incorrect initialization of the number of permits in a semaphore.

Correct the count to the appropriate value.

Table II

CONCURRENCY ANTI-PATTERNS CATALOG(Part 2 of 2)

options regarding how to correct the code fragments. First we need to ensure that both locks are indeed necessary. If any lock is not necessary it should be removed. If all locks are necessary, we next consider whether the locks need to be nested. If not we rewrite the code to separate the critical region into two separate regions each protected by one of the locks. If nested synchronization is necessary, we need to ensure that the lock objects are always acquired in the same order. This example illustrates how a catalog of concurrency anti-patterns can aide in improving the quality of concurrent software. We believe that the benefits of this work fall into three key areas: programming, testing and static analysis.

Programming. There are many examples of software design patterns that have been adopted and used in in-dustry [3], [5]. A benefit of these patterns is that they clearly show good ways (or in the case of anti-patterns bad ways) to design or implement software. The goal of

our concurrency anti-patterns is to provide programmers an additional resource that will assist them in concurrent Java programming by sharing potential problems that should be avoided. The benefit of our anti-patterns is that they help to clarify bad concurrency practices which can assist developers in avoiding concurrency bugs and thus result in improved source code.

(12)

since a race condition or deadlock may only occur in a small subset of the possible interleaving space, the more interleavings we test the higher our confidence that the bug that caused the race condition or deadlock will be found. An example of a tool for executing different thread schedules is ConTest [11].

A catalog of concurrency anti-patterns can benefit concur-rency testing by helping to direct the testing effort. A good understanding of concurrency bugs can provide a tester with more insight into the problems he or she may encounter as well as help a tester focus his or her testing effort within the interleaving space.

Static analysis. Static analysis can be used throughout the software development life cycle and provides useful information about the possible presence of bugs in software. For example, a static analysis tool that detects a match of theDeadlock anti-patternmay help a programmer improve his or her code during implementation or may help catch a bug during testing. Existing static analysis tools, including FindBugs [12], JLint [13] and the Otto-Moschny tool [14], already utilize some concurrency bug patterns in an effort to identify potential problems in concurrent Java source code. Our catalog of concurrency anti-patterns will aide in improving existing tools as well as in the development of new static analysis tools.

IV. DETECTINGCONCURRENCYANTI-PATTERNS In addition to developing our concurrency anti-pattern catalog we have also developed several tools to assist programmers in managing anti-patterns and in identifying potential anti-pattern matches in source code.

A. Concurrency Anti-Pattern Creator

Concurrency anti-patterns can be created and managed using the Concurrency Anti-Pattern Creator tool (see Fig-ure 1). In this tool we define a concurrency anti-pattern as consisting of a name, a problem (with context), a solution, one or more fragments of code as well as a rule about how the fragments interact to cause undesired behaviour. Our experience has shown that many concurrency bugs result in a combination of different code fragments executing in different threads. The interaction of code fragments from different threads is specified in the anti-pattern definition using a rule. Specifically, the rule explains how the code fragments interact to produce erroneous output.

B. Clone-Based Detection of Concurrency Anti-Patterns

One of our goals in creating our concurrency anti-pattern catalog was to also create a static analysis tool to detect possible anti-pattern matches. In our tool, a potential match in source code is made to a known anti-pattern only if all code fragments are present and the rule is satisfied. Our approach takes program source code and anti-patterns as input. The source code is normalized and input to the clone

Figure 1. Concurrency Anti-Pattern Creator

Figure 2. Detection of anti-pattern matches in source code

(13)

anti-pattern we use rule matching to determine if a particular combination of code fragments satisfy the anti-pattern rule. If the rule is satisfied we identify the code fragments as a potential match to our anti-pattern. At this point the developer can use the anti-pattern catalog to determine the appropriate fix (if the match is not a false positive).

An important feature of our detection tool is that it is designed to detect any anti-pattern specified using the Concurrency Anti-Pattern Creator. This feature ensures that the detection tool is flexible enough to be extended to any future anti-patterns that could be added to the catalog. It also means that the catalog can be customized to a particular project or source code repository.

V. CONCLUSION

In this paper we have presented a catalog of programming anti-patterns for concurrent Java that are comprehensive with respect to the programming features available in the Java programming language and comprehensive with respect to an existing concurrency bug pattern taxonomy. We will be making our catalog available publicly2 _{and providing the}

community an opportunity to both use and contribute anti-patterns.

In the future we hope to conduct additional research on the benefits of the catalog with respect to static analysis and testing. We are also interested in studying how these anti-patterns can be utilized in combination with more high-level design patterns [3], [5] and the Hallal et al. anti-patterns [6].

ACKNOWLEDGMENT

The authors would like to thank Shmuel Ur for providing access to IBM Haifa Lab’s Concurrency Bug Benchmark. We would also like to thank the Natural Sciences and Engi-neering Research Council of Canada (NSERC) for funding this research.

REFERENCES

[1] H. Sutter and J. Larus, “Software and the concurrency revo-lution,”Queue, vol. 3, no. 7, pp. 54–62, 2005.

[2] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel,A Pattern Language. Oxford University Press, 1977.

[3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns: Elements of Reusable Object-Oriented Software, ser. Addison-Wesley Professionl Computing Series. Addison Wesley, 1995.

[4] M. Meyer, “Pattern-based reengineering of software systems,” in13th_{Working Conference on Reverse Engineering (WCRE} ’06), 2006, pp. 305–306.

[5] D. Lea,Concurrent Programming in Java: Design Principles and Patterns, Second Edition. Addison Wesley, 2000.

2_{http://svilab.science.uoit.ca/concurr-catalog/}

[6] H. Hallal, E. Alikacem, W. Tunney, S. Boroday, and A. Pe-trenko, “Antipattern-based detection of deficiencies in java multithreaded software,” in4th _{International Conference on} Quality Software (QSIC 2004), 2004, pp. 258–267.

[7] “java.util.concurrent documentation,” Web page: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ package-summary.html.

[8] E. Farchi, Y. Nir, and S. Ur, “Concurrent bug patterns and how to test them,” inProc. of the1st_{International Workshop} on Parallel and Distributed Systems: Testing and Debugging (PADTAD 2003), Apr. 2003.

[9] Y. Eytani and S. Ur, “Compiling a benchmark of documented multi-threaded bugs,” inProc. of the2nd_{International} Work-shop on Parallel and Distributed Systems: Testing and De-bugging (PADTAD 2004), Apr. 2004.

[10] J. S. Bradbury, J. R. Cordy, and J. Dingel, “Mutation operators for concurrent Java (J2SE 5.0),” inProc. of the2nd_Workshop on Mutation Analysis (Mutation 2006), Nov. 2006, pp. 83–92.

[11] O. Edelstein, E. Farchi, Y. Nir, G. Ratsaby, and S. Ur, “Multithreaded Java program test generation.” IBM Systems Journal, vol. 41, no. 1, pp. 111–125, 2002.

[12] “Findbugs - find bugs in Java programs,” Web page: http: //findbugs.sourceforge.net/.

[13] Jlint Manual: Java program checker, Web page: http://artho. com/jlint/manual.html, Jan. 2002.

[14] F. Otto and T. Moschny, “Finding synchronization defects in java programs: extended static analyses and code patterns,” in IWMSE ’08: Proceedings of the 1st international workshop on Multicore software engineering. New York, NY, USA: ACM, 2008, pp. 41–46.

[15] F. Deissenboeck, E. Juergens, B. Hummel, S. Wagner, B. M. y Parareda, and M. Pizka, “Tool support for continuous quality control,” IEEE Software, vol. 25, no. 5, pp. 60–67, 2008.

[16] B. Long, R. Duke, D. Goldson, P. A. Strooper, and L. Wild-man, “Mutation-based exploration of a method for verifying concurrent Java components,” in Proc. of the 2nd Interna-tional Workshop on Parallel and Distributed Systems: Testing and Debugging (PADTAD 2004), Apr. 2004.

[17] B. Long, P. Strooper, and L. Wildman, “A method for verifying concurrent Java components based on an analysis of concurrency failures,”Concurrency and Computation: Prac-tice and Experience, vol. 19, no. 3, pp. 281–294, Mar. 2007.

[18] C. Artho, K. Havelund, and A. Biere, “High-level data races,” in Proc. of the 1st _{International Workshop on Verification} and Validation of Enterprise Information Systems (VVEIS’03), Apr. 2003.

(14)

Abstract Testability Patterns

Wanderlei Souza

State of Sao Paulo Institute for Technological Research Sao Paulo, Brazil

[email protected]

Reginaldo Arakaki

University of Sao Paulo, Polytechnic School Sao Paulo, Brazil

[email protected]

Abstract—Testability is a software quality characteristic that exposes the degree to which a software artifact facilitates the testing process. Software testing is a technical and economical problem, it is important to help identify patterns that would improve the industry’s software testing capabilities. This position paper proposes five abstract patterns that improve software testability, which serves as a reference for testers and developers to evaluate the testability support for high reliable software.

Keywords: Software quality; Design patterns; Design for testability; Software testing; Observability; Built-in testing.

I. INTRODUCTION

The component testability is an important quality characteristic to evaluate the degree to which a software artifact facilitates the testing process. A lower degree of testability results in increased test effort. Depending on the methods used, testing activities account for 25% to 90% of total project effort [1][2][3][4]. Thus, it is important to help identify patterns that would improve the software capabilities of the industry.

Controllability and observability are the key points to testability [5][6]. To test a component it is necessary to control the inputs (controllability) and observe the outputs (observability). Without these key points it is difficult to improve system testability.

Testability patterns proposed in this paper are based on abstract pattern concept described in [7] and correspond to mechanisms or services that increase overall system observability and controllability, these patterns are more general ideas and are not concerned with any specific implementation technique or software development platform. They should not be confused with testability factors or characteristics. Abstract testability patterns correspond to architectural mechanisms, not testability principles.

A software architect uses a distinct pattern collection to design a system. Architectural patterns provide a predefined set of structures, responsibilities, rules and guidelines to organize the relation between system components. A pattern implements a sequence of design decisions to manage certain system quality characteristics. The testability of the architecture was brought up by Nancy Eickelmann and Debra Richardson in [8]. The authors propose that the architectural decisions must be aligned to testing strategies. In this way, the testability of architecture is the combination between architectural patterns and the testing strategy.

II. ABSTRACT TESTABILITY PATTERNS

A. Built-In Self-Testing (BIST)

Problem: Internal components establish connections to external resources (HTTP connections, database systems, remote calls etc.) and do not have a standard interface to validate directly these integrations. The absence of a uniform way to verify all critical integration points after the system deployment process reduces the system testability.

Solution: Built-In Self-Tests (BIST) is a mechanism to self-report the status and health of individual system components. Built-In Self-Tests (BIST) adds standard interfaces to validate core system functionalities and provides many types of validation possibilities. For example, testing the interface between a component and a database system can be accomplished by invoking the BIST to validate the connection and permissions on system tables.

Consequences: Developers must implement a standard test interface in all BIST related classes. In general ways, it is a minimal overhead to development process, but implement a BIST could be more difficult depending on the complexity of the integration under test.

B. Dependency Injection (DI)

Problem: A business component is difficult to test in isolation because it has a direct reference to external dependencies (third-party components, database systems, web services, etc.) and it is not possible to replace the dependency without changing the source code. The main problem roots from the business component creating the external dependencies.

Solution: It is necessary to inject dependencies into a business component, rather than relying on the component to manage the dependencies itself. Dependency injection is a pattern that can be used to improve the software testability by removing the business component responsibility for instantiating its own external dependencies.

Consequences: There is added complexity to the source code and there are more elements to manage on test automation process. Testers must be able to manage mock objects creation and initialization in order to replace the original code dependencies when necessary.

C. Dynamic Component Management Extension

(15)

choose the component concrete implementation dynamically is fundamental to test automation process.

Solution: The system must provide a standard extension to make the system components and services suitable. This extension defines a management architecture to testable components. Using a standard test extension to manage components increases the system testability by making applications more controllable.

Consequences: Dynamic Component Management Extension enables system components management in a test environment. Security barriers or component undeploy must be used to avoid undesired test behavior in a production environment.

D. Testability Logger

Problem: Application events and test related data must be logged for testing purposes. This can lead to redundant code.

Solution: Use the Testability Logger to provide centralized control of logging functionality and takes care of how the testable events are classified and logged. Testability Logger increases the system testability by making applications more observable.

Consequences: The Testability Logger operations (disk IO access, message digests, etc.) impact the system performance.

E. Testability Interceptor

Problem: A tester needs to intercept messages between components for the purpose of verifying the internal behaviors. System also must provide possibility to change application behavior in order to inject and simulate faults in a system.

Solution: Testability Interceptor offers a mechanism to enhance the observability and controllability of a software system by letting components monitor and dynamically change their behavior. Testers can observe and modify functionality without changing the internal logic of components. The Interceptor supports runtime system monitoring and control through Dynamic Component Management Extensions pattern, described in (C).

Consequences: A system design can get more complicated and hard to understand since the developer has to implement the intercepting points.

III. RELATED WORK

Binder [6] presents the Built-In Test concept, a well-known technique for hardware testing, in a software context. We use an abstraction of this concept to describe the Built-In Self-Testing pattern.

Dynamic Component Management Extension is an abstraction layer over JMX technology [9]. We use the JMX ideas and capabilities in order to improve system testability.

The Dependency Injection pattern was first described by Fowler [10] as a specific form of Inversion of Control. We

believe that DI can be used to improve the system testability by abstracting the dependencies out of a component.

The Testability Logger is based on Secure Logger pattern idea [11], but with a focus on system testing and evaluation instead of security reasons.

The Testability Interceptor pattern is related to the Interceptor pattern, which allows services to be added transparently and triggered automatically [12].

IV. CONCLUSION

In this paper we have introduced perspectives to improve system testability and propose a new architectural pattern category: testability patterns. Future work includes other ideas to architectural testability patterns and concrete implementations.

A Java based concrete implementation of these abstract patterns has been used to improve the testability of critical Internet systems in the main portal to content & the Internet provider in Brazil.

REFERENCES

[1] S. Jungmayr, “Reviewing Software Artifacts for Testability”, Proc. of EuroSTAR’99, Barcelona, Spain, November 10-12, 1999.

[2] R. S. Pressman, “Software Engineering: Practitioner’s Approach”, European 3rd_{Edition, McGraw-Hill Book Company, Berkshire,}

England, 1994, pp. 609.

[3] Tim Koomen and Martin Pol, “Test Process Improvement: A Practical Step-by-Step Guide to Structured Testing”, Addison-Wesley, 1999.

[4] B. Beizer, “Software Testing Techniques”, International Thomson Computer Press, Boston, 1990.

[5] Roy S. Freedman, “Testability of Software Components”, IEEE Transactions on Software Engineering, Vol. 17, No. 6, 1991. [6] Robert V. Binder, “Design for Testability in Object-Oriented

Systems”, Communications of the ACM, v.37 n.9, 1994.

[7] Eduardo B. Fernandez, Hironori Washizaki and Nobukazu Yoshioka, “Abstract Security Patterns”, 2nd_{International workshop on software}

patterns and quality (SPAQu'08), 2008.

[8] Nancy S. Eickelmann and Debra J. Richardson, “What makes one software architecture more testable than other?”, Joint proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints '96) on SIGSOFT '96 workshops, San Francisco, California, 1996, pp. 65.

[9] H. Kreger, “Java management extensions for application management”, IBM Journal of Research and Development, IBM Corp. Riverton, NJ, 2001.

[10] Martin Fowler, “Inversion of Control containers and the Dependency Injection pattern”, http://martinfowler.com, 2004.

[11] Christopher Steel, Ramesh Nagappan and Ray Lai, “Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management”, Prentice Hall PTR, 2006, pp. 577.

(16)

Towards an Assessment of the Quality of Refactoring Patterns

Norihiro Yoshida, Masatomo Yoshida, Katsuro Inoue

Graduate School of Information Science and Technorogy, Osaka University 1-5 Yamadaoka, Suita, Osaka, 565-0871, Japan

Email:{n-yosida, mstm-ysd, inoue}@ist.osaka-u.ac.jp

Abstract—Refactoring is a well-known process that is

thought to improve the maintainability of object-oriented software. Although a lot of refactoring patterns are introduced in several pieces of literature, the quality of refactoring patterns is not always discussed. Therefore, it is difficult for developers to determine which refactoring patterns should be given priority. In this paper, we propose two quality characteristics of refactoring pattern, and then describe an open source case study on assessing those quality characteristics.

Keywords-refactoring; quality of software pattern;

object-oriented programing; software maintenance;

I. INTRODUCTION

Refactoring [1] is the process of changing a software

system in such a way that it does not alter the external behavior of the code yet improves its internal structure. That is to say, refactoring is a process to improve the maintainability of software systems.

Several practitioners introduce a lot of Refactoring

Pat-terns (RP) [1][2]. Each RP includes both a description of a refactoring opportunity (RO) (i.e., a set of code fragments

that should be refactored) and the corresponding procedure to perform refactoring (i.e., how to perform refactoring). However, the quality of each refactoring pattern is mostly never assessed. Therefore, it is difficult for developers to de-termine which refactoring patterns should be given priority. In this paper, we propose two quality characteristics of RPs, and then describe a case study on assessing those quality characteristics.

II. PROPOSED QUALITY CHARACTERISTICS OF REFACTORING PATTERNS

We introduce the following two quality characteristics of RP.

• Number of ROs: Because a lot of refactoring patterns

exist and developers have only a limited time, it is desirable to choose RPs that have a lot of ROs.

• Ease of Refactoring: It means that ease of applying

each RP to ROs in source code. When the ease of refactoring of a RP is high, it means that software sys-tems involve a lot of ROs that can be easily performed refactoring. A RP that is difficult to apply often leads to time-consuming refactoring. Because the aim of refac-toring is to reduce maintenance cost, time-consuming refactoring is not desirable. There are two kinds of

refactoring pattern. The first one requires developers to apply only steps described in its description. On the other hand, another sometimes requires developers to apply not only steps described in its description but also additional steps.

III. CASESTUDY

In this section, we assess the quality characteristics of RP which is named Introduce Polymorphic Creation with

Factory Method (IPCFM) [2].

We introduce IPCFM and an automated method to identify ROs in software systems for IPCFM. Then, we discuss the ROs in several software systems from proposed quality characteristics of RP.

A. Introduce polymorphic creation with factory method

IPCFM is a kind of Pull up Method [1] pattern that is aimed at merging similar methods from different classes into a common superclass. Figure 1 shows an example of IPCFM. The aim of IPCFM is to merge similar methods except for object creation statements by introducing factory methods. An RO for IPCFM is defined as “Classes in a hierarchy implement a method similarly except for an object creation step” [2].

As shown in Figure 1(a), the targets of the refactoring

are the test classesDOMBuilderTestandXMLBuilderTest

for testingDOMBuilderandXMLBuilder, respectively.

Be-cause the target classes have similar methods except for an object creation step, they indicate an RO for applying IPCFM. This refactoring is comprised of following two steps.

Step1 As shown in Figure 1(b), a common superclass (AbstractBuilderTest) for the target classes is in-troduced, and similar methods in the target classes are merged into new method in the common su-perclass.

Step2 A factory method is introduced in each of

the common superclass (AbstractBuilderTest)

and the subclasses (DOMBuilderTest and

XML-BuilderTest). B. Assessment Method

(17)

+testAddAboveRoot() : void

DOMBuilderTest XMLBuilderTest junit::framework::TestCase

・・・

builder = new DOMBuilder(“orders”); ・・・

・・・

builder = new XMLBuilder(“orders”); ・・・

Similar methods (Code clones)

DOMBuilderTest XMLBuilderTest junit::framework::TestCase

・・・

builder = new DOMBuilder(“orders”); ・・・

・・・

builder = new XMLBuilder(“orders”); ・・・

Similar methods (Code clones)

(a) Before refactoring

Factory Method: Creator

#createBuilder(rootName : String) : OutputBuilder +testAddAboveRoot() : void

AbstractBuilderTest

junit::framework::TestCase

#builder: OutputBuilder

・・・

builder = createBuilder(“orders”); ・・・

DOMBuilderTest

Factory Method: ConcreteCreator

return new DOMBuilder(rootName); return new XMLBuilder(rootName);

#createBuilder(rootName:String) : OutputBuilder

XMLBuilderTest

#createBuilder(rootName:String) : OutputBuilder Factory Method: Creator

#createBuilder(rootName : String) : OutputBuilder +testAddAboveRoot() : void

AbstractBuilderTest

junit::framework::TestCase

#builder: OutputBuilder

・・・

builder = createBuilder(“orders”); ・・・

DOMBuilderTest

Factory Method: ConcreteCreator

return new DOMBuilder(rootName); return new XMLBuilder(rootName);

XMLBuilderTest

(b) After refactoring

Figure 1. Introduce Polymorphic Creation with Factory Method

Step1 Detect similar methods using a code clone

detec-tion tool CCFinder [3]1_.

Step2 Evaluate whether detected methods belong to classes that have common superclasses in target source code and whether they include object cre-ation statements.

We apply the target RP to the ROs inAnt andANTLR.

To assess the ease of refactoring, we confirm the steps that are not described in the description of the target RP.

C. Results

Table I includes the result of identifying ROs for IPCFM in several software systems. For comparison, in Table I, we show the number of ROs for Pull up Method (PM). We identify ROs for PM by detecting code clones belonging to classes that have common superclasses. We should note that because IPCFM is kind of PM, an RO for IPCFM is counted towards the number of ROs for PM. According to Table I, 17.9% of the ROs for PM are the ROs for IPCFM. We can say that ROs for PM includes more than few ROs for IPCFM. This indicates that when developers found RO

1_{In our case study, we set 30 tokens as the minimum length of code}

clone.

for PM, they should inspect whether those RO are also for IPCFM.

When we apply IPCFM to all ROs inAntandANTLR, we

did not have to apply additional steps that are not described in the description of IPCFM. This result indicates that the ease of refactoring of IPCFM is high.

IV. RELATEDWORKS

Hsueh, et al.[4] and Huston[5] focus on the quality of design patterns. We focus on the quality of RPs, and propose the two novel quality characteristics of RPs.

V. SUMMARY ANDFUTURE WORK

In this paper, we proposed two quality characteristics of RP, and then described a case study on assessing those quality characteristics of IPCFM. To compare the quality characteristics of RP, we are planning to assess other RPs. We should discuss not only proposed quality characteristics but also change in maintainability because the aim of refac-toring is to reduce maintenance cost.

ACKNOWLEDGMENT

We thank the anonymous SPAQu’09 reviewers for useful feedback on earlier versions of this paper. This reseach was supported by JSPS, Grant-in-Aid for Scientific Research (A) (No.21240002) and Grant-in-Aid for JSPS Fellows (No.20-1964).

REFERENCES

[1] M. Fowler, Refactoring: improving the design of existing code. Addison Wesley, 1999.

[2] J. Kerievsky, Refactoring to Patterns. Addison Wesley, 2004.

[3] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A mul-tilinguistic token-based code clone detection system for large scale source code,” IEEE Trans. Sofw. Eng., vol. 28, no. 7, pp. 654–670, 2002.

[4] N.-L. Hsueh, P.-H. Chu, and W. Chu, “A quantitative approach for evaluating the quality of design patterns,” Journal of

Systems and Software, vol. 81, no. 8, pp. 1430–1439, 2008.

[5] B. Huston, “The effects of design pattern application on metric scores,” Journal of Systems and Software, vol. 58, no. 3, pp. 261–269, 2001.

Table I

NUMBER OFROS FORIPCFM

name LOC #classes #opportunities IPCFM PM

Ant 1.7.0 198K 994 2 23

ANTLR 2.7.4 32K 167 1 33

Azureus 3.0.3.4 538K 2226 20 42

JEdit 4.3 168K 992 0 1

JHotDraw 7.0.9 90K 487 1 26

SableCC 3.2 35K 237 0 1

Soot 2.2.4 352K 2298 5 53

(18)

On the Symbiosis between Quality and Patterns

Pankaj Kamthan

Department of Computer Science and Software Engineering Concordia University

Montreal, Quebec, Canada H3G 1M8 [email protected]

Abstract—This position paper proposes that the impact on the quality of a software system by using patterns is intrinsically related to the quality of the patterns themselves. In doing so, it presents some of the challenges being faced and hints towards potential resolutions.

Pattern Description, Pattern Stakeholder, Semiotic Quality

I. INTRODUCTION

For the sake of this paper, a pattern is an empirically proven solution to a recurring problem in a particular context. For simplicity, two classes of stakeholders of a pattern, namely pattern producers and pattern consumers, are considered. The rest of the paper explores the interdependence of the notions of patterns for quality and quality of patterns.

II. A PERSPECTIVE ON QUALITY

For the sake of this paper, quality is defined using the ISO/IEC 9126-1:2001(E) as “the totality of [attributes] of an entity that bear on its ability to satisfy stated and implied needs.” The notion of quality is multifaceted. These facets include the entity of interest, the viewpoint on that entity, and quality attributes of that entity.

There are a number of possible viewpoints of quality. In one of the earliest approaches towards perceptions of quality [4], the five views of quality are identified: (QV1) the transcendental-based view (quality is perfective), (QV2) the product-based view (quality is measurable), (QV3) the manufacturing-based view (quality is conformance), (QV4) the economics-based view (quality is benefit for cost), and (QV5) the user-based view (quality is satisfaction).

Indeed, multiple views may need to be satisfied in addressing quality of a software system. For example, the ISO/IEC 9126-1:2001(E) presents an intersection of QV2, QV4, and QV5. Furthermore, due to practical considerations, QV4 constrains QV1. Therefore, any initiatives towards quality assurance or evaluation need to end if the cost exceeds the benefit. There are no studies in the current literature on the return on investment (ROI) of using patterns, for the purpose of aiding quality of a software system or otherwise.

III. PATTERNS FOR QUALITY

There are a number of approaches for quality assurance and evaluation. The use of a pattern is a preventative approach to

quality, as opposed to inspections or testing that are curative approaches.

Let S be a software system under development. Let FR be a functional requirement for S. A realization of FR is constrained by certain expectations of quality. If a pattern P is to be selected for S, then a number of conditions must be satisfied:

• Context. The context of P must subsume that of S. This means that the description of P must make the context explicit.

• Problem. The problem of P must be aligned with FR. This means that the description of P must make the problem explicit.

• Forces. A quality model is useful for creating an understanding of quality. There is currently no single, universal quality model that is applicable to all software systems. Let QM be a quality model associated with S. Let the quality attributes in QM be prioritized as QA1 ≥ … ≥ QAn, where ≤ is some total ordering. The forces of P must to be aligned with QM. In other words, the highest priority forces that the solution of P resolves must also be the highest priority in QA1 ≥ … ≥ QAn. Thus, P may aid some but not other quality attributes of S. The view of quality of the software engineers of S and producers of P may not be identical. Indeed, it has been shown empirically [5] that the relationship between quality of S and the patterns used in the development of S is equivocal. This also means that the description of P must make the forces explicit [1]. In turn, these usually imply that the description of P is structured in some way. It is possible to impose a structure on a pattern by adopting a pattern form. There is currently no single pattern form followed by pattern producers. This makes a systematic comparison of patterns in general and an assessment of their impact on quality of a software system in particular difficult.

IV. QUALITY OF PATTERNS

There is guidance available for describing patterns [6]. However, currently there is no acceptable definition of quality of a pattern and no general quality model for patterns.

(19)

physical, empirical, syntactic, semantic, pragmatic, and social. In this paper, the interest is in pragmatic quality of a pattern, which is a contract between a pattern and its stakeholders.

The quality of a pattern needs to be studied at two levels: (1) at the pattern description level and (2) at the individual pattern element level.

A. Quality of a Pattern at the Description Level

The quality attributes such as accessibility/usability and maintainability are part of pragmatic quality, and apply to a pattern description as a whole. There are a number of issues that can arise at the description level:

• Accessibility/Usability. These are of concern to pattern consumers. A pattern description, especially that made available only via repositories on the Web, can have accessibility (as per ISO 9241-171:2008)/usability (as per ISO/IEC 9126-1:2001(E)) issues. For example, there are pattern descriptions that do not pass the W3C Web Content Accessibility Guidelines (WCAG) and users have found difficulties in reading and navigating pattern descriptions available on pattern repositories [7].

• Maintainability. This is of concern to pattern producers. A pattern description may need to evolve for a number of reasons including discovery of errors that need to be rectified, modification in technologies illustrating the solution, presentation on a device not targeted originally, and so on. For example, software engineers trained in this century may be more familiar with the Unified Modeling Language (UML) than with the notations used in describing the solutions of the patterns of the 1990s.

B. Quality of a Pattern at the Element Level

A pattern form can have a number of mandatory and optional elements [2, 6]. The elements that are considered mandatory are: (pattern) name, context, problem, forces, and solution. The optional elements that can be useful include examples and resulting context. There are a number of issues that can arise at the element level:

• Name. The name of a pattern may not be evocative [2] or pronounceable. This can be an impediment on the selection of patterns and use of patterns for communication by its consumers.

• Context. The context of a pattern may not be explicitly stated. This can be an obstacle towards the selection of patterns. For example, the COLOR-CODED SECTIONS pattern [8] is not suitable for situations where the users have some form of color deficiency.

• Problem. The problem of a pattern may not be explicitly stated [3] and/or may not be context-free. In general, the problem description can suffer from the issues that affect a software requirement statement.

• Forces. The forces of a pattern may not be explicitly highlighted. For example, it is possible to make the forces explicit by listing them individually. For a given

problem in the development of S, let there be multiple candidate patterns, say, pattern complements [2]. Then, the absence of forces makes it difficult to select the appropriate pattern.

• Solution. It is evident that the quality of the solution of a pattern will directly affect the quality of S as this is the place where conceptual reuse is realized. However, the solution of a pattern could contain errors [3].

• Examples. The solution of a pattern may not have gone through an evaluation, at one of the *PLoP ‘family’ of conferences or otherwise, and may not include three examples as suggested by the ‘patternity test’ [2].

• Resulting Context. The consequences of applying a pattern may not be discussed. In such a case, the forces that the solution resolves, partially or completely, and the ones it does not resolve, may not be known.

V. CONCLUSION

If patterns are to be considered as entities of conceptually reusable knowledge that lead to the development of ‘high-quality’ software systems, then the quality of these patterns themselves must be considered as a first-class concern, and should be treated as such. It is the exploration of the semiotic quality of a pattern that is of particular interest. Indeed, a semiotic quality model for pattern descriptions could be useful in the selection of the appropriate pattern from a given set of patterns that span multiple pattern collections such as different pattern languages.

ACKNOWLEDGMENT

The author is thankful to Peter Grogono for useful discussions, and to the reviewers for detailed feedback and suggestions for improvement.

REFERENCES

[1] I. Araujo and M. Weiss, “Linking Patterns and Non-Functional Requirements,” The Ninth Conference on Pattern Languages of Programs (PLoP 2002), Monticello, U.S.A., September 8-12, 2002. [2] F. Buschmann, K. Henney, and D. C. Schmidt, “Pattern-Oriented

Software Architecture, Volume 5: On Patterns and Pattern Languages,” 2007, John Wiley & Sons.

[3] M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, “Patterns of Enterprise Application Architecture,” 2003, Addison-Wesley.

[4] D. A. Garvin, “What does Product Quality Really Mean?” MIT Sloan Management Review, Vol. 26, No. 1, 1984, pp. 25-43.

[5] F. Khomh and Y. -G. Guéhéneuc, “Perception and Reality: What are Design Patterns Good For?” The Eleventh ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2007), Berlin, Germany, July 31, 2007.

[6] G. Meszaros and J. Doble, “A Pattern Language for Pattern Writing,” in: Pattern Languages of Program Design 3. R. C. Martin, D. Riehle, and F. Buschmann, Eds. Addison-Wesley, 1998, pp. 529-574.

[7] K. Segerståhl and T. Jokela, “Usability of Interaction Patterns,” The ACM CHI 2006 Conference on Human Factors in Computing Systems (CHI 2006), Montreal, Canada, April 22-27, 2006.

(20)

(21)

(22)

Generic Patterns: Bridging the Contextual Divide

Marc Boyer

Computer Science Department University of Manitoba Winnipeg, MB, Canada [email protected]

Vojislav B. Miši

ć

School of Computer Science Ryerson University Toronto, ON, Canada

[email protected]

Abstract—Correct application of design patterns requires bridging the cognitive gap between the problem and implementation domains, as well as identifying the proper pattern amongst many to use in correctly modeling the user domain. As a result, pattern-based design is neither as efficient nor as effective as it might be. Hence, we propose an improved two-step pattern design process: first pick a pattern that matches domain requirements from a small number of generic, context-free patterns; then concretize the pattern further into one of the industry-standard, context-dependent patterns. In this manner, identifying patterns in requirements tightly bound to their context becomes both faster and more accurate, as demonstrated in a real-world example.

Keywords-software design, design patterns, design quality

I. INTRODUCTION

Ever since their introduction in the mid-nineties [3][6], design patterns and their siblings at various levels of abstraction [4][5] have been advertised as being one of the most efficient ways to reuse design knowledge: "each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem …" [2]. The traditional approach to using design patterns, as advocated by the original authors [3][6], relies on analyzing requirements, identifying the patterns therein, and then using the patterns to model the software’s concrete elements: functional classes, instantiated objects, and their interactions. In this manner, design patterns lead to reuse of software engineering knowledge, and ultimately lead to an increase in designer productivity and an improvement in the quality of software products.

Yet despite extensive training and a wealth of pattern-related information (including a number of catalogs [7]), proper use of patterns is still problematic [1][9][11], and advertised benefits of patterns and pattern-based approaches to software design are still hard to realize in practice. What is the cause of this discrepancy: are people misusing available design patterns? Are requirements too complex to model using available design patterns? Or is the main reason for the discrepancy between promise and reality the cognitive gap between the domain requirements and the pattern descriptions [17], and perhaps even the insufficient discriminatory power of the pattern descriptions themselves?

To remedy this situation, we propose a set of generic or context-free patterns that can be more easily identified

within domain requirements, and a two-stage design process through which the generic patterns can be concretized to one of the already-known, industry-standard, context-dependent patterns.

The paper is organized as follows: in Section II we discuss briefly the limitations of the traditional pattern-based techniques used to design software, and illustrate the problem with experimental findings. We also discuss more recent techniques used to address these limitations, and explain why they may not deliver the anticipated rewards of using design patterns to model software. Section III outlines the proposed approach to mapping requirements to models using context-free patterns, with a small example. Section IV concludes the paper and discusses areas of further research.

II. PATTERN PROBLEMS AND SOLUTIONS

In the traditional pattern-based design approach, designers analyze the requirements and use a design pattern to map them to a software model [3][6]. Patterns are sought and identified in the domain requirements, thus providing the foundation upon which full-fledged software designs are developed. The right pattern is identified by matching the contextual elements discerned in the domain requirements with the problem context elements provided by the pattern description. Once identified and applied, patterns are subsequently enriched by adding appropriate detail, and rendered concrete so as to facilitate their implementation through coding.